The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also be inventions.
Entering data into a software application is a common process in many online computer applications and web sites. In web sites and web based (browser rendered) applications, this is commonly done using HTML (HyperText Markup Language) forms. In this case, specific tags or elements within the HTML standard such as <input>, <textarea>, <select>, and so on, are used to define screen areas in which user input is to be received. Such input can be in the form of text typed into rectangular fields, boxes that are selected or deselected, and other graphical user input elements. The form elements are rendered in the client browser at a specific size, normally determined by a combination of web browser, CSS (Cascading Style Sheets), JavaScript, and HTML attributes. To enhance the user experience and facilitate interactivity, application designers and developers commonly attempt to provide input fields and other form elements in a size and arrangement that will best suit the expected data. For example a telephone number field in an application localized for the United States consumer market might appear on the form as: (——————)——————-——————. This format exactly fits the expected data of a three digit area code, three digit prefix, and a four digit suffix, and allows the user to simply enter his or her phone number without guessing how the number is to be entered (e.g., with or without the area code or dash).
Many items of input data, however, may not be as easily definable as U.S. phone numbers. In cases where the expected data is relatively unknown, or open to various possible formats, the application must employ a particular design approach to allow for consistent data processing. Examples of typical current design approaches include (1) making a best educated guess of input format based on similar forms used in the past, if any exist; (2) implementing a worst case scenario handler, such as making a field large enough and unformatted so that any conceivable input string will fit; (3) making the fields customizable through application-level, role-level, or user-level preferences; or (4) making the fields customizable on the rendered page through resize controls, or drag and drop resizing and placement operations. There are significant disadvantages with each of these approaches. For example, option 1 is not always viable, especially in distributed enterprise software applications where customers are allowed to use a development toolkit to use build any application they wish and that may include a long list of available object and data types. Option 2 requires reserving large spaces in the page layout that may never even get used, thus causing resource inefficiencies in the application and persistence layers, which is not ideal for performance, scalability, readability, and usability. Options 3 and 4 each add complexity to the code and the user experience, thus increasing chances for bugs and the amount of required training, maintenance, and support costs.
Accordingly, it is desirable to provide techniques enabling efficient and effective user interaction with electronic or online data entry forms through input fields that are optimized based on the type and format of the entered data and the application that is processing this data. Embodiments of currently described approach do not necessarily try to increase the likelihood of page interaction or form submission, as it is assumed that the form will be viewed and filled out and submitted by the user. Instead, the goal is to make the data entry process easier and more accurate.